package main

func main() {
	//Log包很重要

	/*

		开发，debug，故障排查，数据分析，监控告警，保存现场
		我们需要设计一个优秀的日志包，如果我们要扩展就比较麻烦，1．基于zap封装，2．自己实现3．改zap的源码
		1．是否可以替换 后期我们想要替换成另一个日志框架
		2．我们要考虑扩展性，log打印的时候是否支持打印当前的goroutine的id 是否支持打印当前的context
		3．我们给大家提供的日志包，还能支持集成tracing（open-telemetry，metrics，logging），就可以集成jaeger
		4．是否每个日志打印都能知道这个日志是哪个请求的
		封装日志包很重要！最好是自己封装

	*/

	//gorm，go-redis、我们自己业务代码
	/*
					logger最基本的功能
						1．日志基本 debug、info、warn、error、fatal、panic
						2．打印方式2020-12-02T01：16：18＋08：00 INFO example．go：11 std log json （zap）
						3．日志是否支持轮转、单文件不能太大，压缩，切割
				        4.日志包是否支持hook，gorm
			        其他需求：
						是否支持颜色显示
		                是否兼容表中的Log
						error打印到error文件，info打印到info文件
						error能否发送到其他的监控软件，统计一个metrics错误指标
					    error是否能支持发送到jaeger

		其他需求：
			高性能
			并发安全
			插件化：错误告警，发邮件 sentry参数控制

		基于zap封装
	*/

	/*
		log使用经验
			1．if分支的时候可以打印日志
			2．写操作要尽量写日志 gorm，要记录数据
			3．for循环打印日志的时候要慎重，for循环会运行上万次
			4．错误产生的原始位置打印日志A（这里打印行不行）—＞B—＞C（error，应该在此处打印日志）所有error一律采用记录stack同时采用faiL fast
		debug:
			我们为了方便排查错误很多时候会在很多地方使用debug，debug往往很多，上了生产如果开启debug会导致性能受影响，在上线的时候尽量关闭到debug

		info:
			关键的地方打印一些信息，这些信息数据可以交给大数据进行分析，info量来说相对比较适中。如果你发现了你的info使用量特别大，你就该考虑是否用debug
		I
		warn:
			warn往往不会导致一个请求失败，但是我们还是应该关注的一些数据，这是一种爬虫行为

		error:
			这就是程序失败，我们的函数没有做好错误兼容，由于业务运行过程中的bug，请求第三方资源，创建数据集记录，这种错误一定要关注

		panic:
			panic会导致整个系统直接挂掉，我们一开始项目启动的时候会连接数据库，可以使用panic去结束掉程序，panic是可以被recover住的
			有一些情况比如slice越界 2／0，业务中遇到这种panic你的程序挂了这就要命了

		Fatal:
			最高级别的错误，当你使用这个方法的时候你心里应该清楚，这个错误不应该被原谅，就应该导致程序挂掉

	*/

	/*

		写日志的注意事项
			1．日志中不能记录敏感数据，不能写密码，token
			2．日志打印的时候尽量写清楚错误的原因 log．Warnf（＂［getDB］ init database： ％v＂， err）
			3．如果可以，每一条日志尽量和请求的id关联起来
			4．info和error不要乱用，很常见
		实践
			1．好的日志不可能一开始就设计的很好，这是一个演进的过程，日志打印要重视
			2．日志不是越多越好，越少越好，关键要打印
			3．日志要兼容本地打印
			4．能否支持动态调整日志级别
	*/

	/*
				container -> console -> shipper(logstash/flume/fluentd) -> kafka -> es -> kibana
			          |                                                          -> loki
		              V
			         file -> kafka -> consumer -> hdfs

	*/
}
